What I'm currently not sure of if this should run on a time-trigger, on dispatch or if we just keep this PR open until the infra-outage is fixed and rebase/rerun it on our own discretion if desired.

I think doing it in a nightly way as (temporary) replacement of I-Builds would make sense. In addition, I would be in favor of adding the workflow_dispatch event, so that we can manually trigger it on demand. That might be useful even beyond the current infrastructure issues.

Probably due to eclipse-platform/eclipse.platform.swt#2077, the workarounds to make swt.svg compile are not necessary anymore. Thanks for the fix.
But still this fails with javadoc generation errors:

Error:  Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.11.2:jar (attach-javadocs) on project org.eclipse.swt.gtk.linux.x86_64: MavenReportException: Error while generating Javadoc: 
Error:  Exit code: 1
Error:  /home/runner/work/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/Converter.java:34: error: bad HTML entity
Error:   * About JNI & string conversion:
Error:               ^
Error:  /home/runner/work/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/Converter.java:53: error: bad HTML entity
Error:   * About encoding on Linux/Gtk & it's relevance to SWT:
Error:                                 ^
Error:  /home/runner/work/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/Converter.java:58: error: bad HTML entity
Error:   * UTF-8 = minimum is 8 bits, max is 6 bytes, but rarely goes beyond 4 bytes. Gtk & most of web uses this.
Error:                                                                                    ^
Error:  /home/runner/work/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/org/eclipse/swt/internal/gtk/OS.java:453: error: unknown tag: method
Error:  	/** @method flags=no_gen

And currently I have no idea why.

And currently I have no idea why.

& needs to be escaped as & and @method is not a valid javadoc tag

And currently I have no idea why.

& needs to be escaped as & and @method is not a valid javadoc tag

Yes sure, I meant why this does not appear somewhere else. But I just noticed that SWT is the only project that doesn't build the javadoc in verification builds. I'm about that change that and fix all the errors in:

• [Build] Activate javadoc generation and 'bree-libs' profile eclipse.platform.swt#2079

@HannesWell You can of course just remove my commit in this PR instead of adding a revert commit. It was just for testing purposes to work around the infrastructure issues but it turned out that one of the issues was actually a general build issue that meanwhile was fixed: eclipse-platform/eclipse.platform.swt#2077

Even though the infrastructure issues have been resolved for now, I would be in favor of contributing this workflow to be dispatched manually, so that one can trigger an aggregator build if required without waiting for the nightly I-Build. One possible extension might be to introduce a branch tag pattern to execute the workflow, such that one can for example test changes across multiple repos by changing the .gitmodules branches accordingly and then triggering the workflow proposed here on that state.

What is the status of this one?

What is the status of this one?

Even though the infrastructure issues have been resolved for now, I would be in favor of contributing this workflow to be dispatched manually, so that one can trigger an aggregator build if required without waiting for the nightly I-Build. One possible extension might be to introduce a branch tag pattern to execute the workflow, such that one can for example test changes across multiple repos by changing the .gitmodules branches accordingly and then triggering the workflow proposed here on that state.

That's already possible with the Jenkins job.

What is the status of this one?

I have to admit that I'm not sure how we should use this in practice in relevant cases.
Therefore I would be in favor to abandon this. If we find use-cases later, this can still be reopend.